This invention relates to the field of port identification in a network host connection. In particular, the invention relates to correct port identification in a network host connection when a user is connecting to a network service.
In computer networks, a port is provided as a communication endpoint at a network host or node. A port is associated with an Internet Protocol (IP) address of the network host. The host or node may be a server in the network.
A port is used to identify different applications or processes running on a host enabling them to share a single physical connection to the network. The protocols that mainly use ports are the transport layer protocols, for example, Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).
A port is identified for each address and protocol by a 16-bit number, known as the port number. The port number plus a computer's IP address forms the destination address for a communications session. Data packets may be routed across a network to a destination IP address, and then further routed to the specific process bound to the destination port number.
In one scenario, a server can have more than one way for an Internet protocol suite (TCP/IP) connection to be established to it, such as one for a debug listener agent and one for a runtime application programming interface (API), or different uniform resource locators (URLs) for different types of services.
A user or client may know the server name and a message, but may either not know the port or may specify an incorrect port.
An example of this may be considered in a database, an application server, or a message queue manager where different ports are configured for different purposes, such as for connection purposes to get and put data, or for debugging, or issuing Structured Query Language (SQL) commands, and so forth.
The client may know a message, e.g. “http://server:port/startdebug=true”, or “http://server:port/getqueue?name=fred”, and the client may know the server, but they do not know the port which is the variable portion.
A ping command allows a client to test whether a server:port combination has a listener on it, in which case a port can be pinged and will reply. This enables a user to test whether a port is active. However, it is not possible to test which port is configured for which protocol.
One technique is to test every single port for the message. The problem with this is that the message sent to the wrong port might have undesired effects. It could, in the worst case, crash and bring down another server or cause unexpected data corruption. Therefore, this kind of message shotgun approach is not generally encouraged.
An example of an incorrect port being specified is described in a transactions server such as Customer Information Control System (CICS) of International Business Machines Corporation (CICS is a trade mark of International Business Machines Corporation, registered in many jurisdictions).
A CICS region may have different ports for connecting to it for its systems management API—one for a connection type known as “CPSM Data” (CICSPlex System Manager Data) for older CICS regions and one for a connection type known as “CMCI” (CICS Management Client Interface) for newer CICS regions (CICSPlex is a trade mark of International Business Machines Corporation, registered in many jurisdictions). A CICS region can also have other ports defined to it that route to other programs running other services, such as for CICS tools or debug ports.
The problem that users encounter is that they try to connect to a particular service, and specify the wrong port. They do not receive the equivalent of an error message that the port is unavailable, instead the error they receive is where the application has typically tried to send a message for one program/service to another program/service and unpredictable results have occurred. Often this can be a SAX (Simple API for XML) parse exception where XML (Extensible Markup Language) was expected but HTML (HyperText Markup Language) was returned, or a “missing <hr>” tag where HTML was expected but XML was received, and so forth. At best, the application might parse the response and just inform the user that they have specified the wrong port. In this case, the user either has to change the port, or change the type of connection they are to establish.
A known solution to this is for the user to diagnose the error they have got as being the symptom of having connected to the wrong port, and for them to either change the port or change the type of connection they are establishing. This is time consuming, and it involves the user knowing the correct alternative port.
Therefore, there is a need in the art to address the aforementioned problems.